(1) Field of the Invention
The present invention relates to real-time database systems and more particularly to a real-time method for recording data in a database which maintains database consistency in the event of a system failure.
(2) Description of the Prior Art
It is well known that database systems fail for a variety of reasons. The computer hardware can fail, the storage media can fail, or the transaction processing software can fail. System failures cause loss of volatile main memory storage, transaction failures cause an abnormal termination of a transaction, and media failures cause a loss of secondary nonvolatile storage.
Failure recovery must ensure that the database remains consistent after one of these failures. Redundant media storage and shadowing the database across the redundant media allows recovery if one set of the media fails. Shadowing the data requires changes to be written to both copies of the database without interruption. On failure, the shadow database becomes the primary database, and the database system can continue to operate. Of more interest are system and transaction errors because these errors are expected more frequently, and recovery from these errors must be efficiently supported. A typical transaction error called "deadlock" occurs when two transactions are waiting on each other to complete usage of a particular data set, and each transaction has locked the data needed by the other. The usual solution to this error is to abort one of the two conflicting transactions and then restart the transaction.
When a hardware or power failure occurs, information contained in primary memory such as random access memory (RAM) is considered lost. With this type of failure, transactions are left in one of two states; those committed before the failure, and those active but not committed before the failure. Committed transactions are those transactions which have been copied from the primary memory to a stable computer database media such as a magnetic disk, optical disk, or magnetic tape. Recovery must ensure that committed transactions remain committed and active transactions do not cause database inconsistencies upon reactivation.
Conventional means for recovery of committed and active transactions use non-volatile checkpointing to mark data items which have been committed. Upon recovery from the system error, check pointed transactions are completed to make permanent the changes specified by those transactions. Any database changes made by the uncommitted transactions are restored to the state which existed before the transaction was performed. Undone transactions can be restarted at some later time. Some disadvantages of this system are that it requires the maintenance of a log for all database operations for use in restoring a database in some previous state. During recovery, the system applies the log to the entire transaction requiring the entire transaction to be undone or redone, and during recovery the database is unavailable for use.